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Supply  Chains 


Supply  chain:  set  of  suppliers  that  contribute  to  the 
content  of  a  product  or  system  or  that  have 

opportunity  to  modify  its  content.  (Comprehensive  National  Cybersecurity 

Initiative  1 1 ) 


Hardware  product  involves  multiple  deliveries  of  the 
same  item  (built  to  specification) 

Software  product  is  typically  a  single  item 
redistributed  within  an  organization 
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Supply-Chain  Risk 


Hardware  supply  chains  -  decades  of  data  collection 

•  Manufacturing  and  delivery  disruptions 

•  Manufacturing  quality 

•  Counterfeit  hardware  estimated  at  10% 

Software  -  little  data  for  software  supply  chains 

•  Third-party  tampering  during  development  or  delivery 

•  Malicious  supplier 

•  Compromised  by  inadvertent  introduction  of  exploitable 
design  or  coding  errors 
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Software  Supply  Chain  Risk  Management 


Attack  Analysis 


Acquirers 


Factors  that  lead  to  successful 
attacks 


Suppliers 

Risk-based  development 

Capability  to  limit  product 
attributes  that  enable  attacks 


Tradeoff  decisions  between  desired  use 
and  acceptable  business  risk 

Uncertainty  for  product/supplier  assurance 

limited  supply  chain  visibility  and 
controls 

evolving  nature  of  threats,  usage,  & 
product  functionality 

Continued  supply  chain  risk  management 
during  deployment 
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Attack  Example:  Stuxnet 


Enabled  the  attacker  to  modify  how  the  control  system  managed  a  physical 
system.  General  purpose  control  systems  such  as  Siemens’  execute  user 
supplied  software  designed  for  the  specific  application. 

Strategy: 

To  avoid  detection,  do  not  use  corporate  networks  to  directly  modify 
the  control  system  software 

Use  Internet  access  and  defects  in  Windows  or  in  application 
software  to  compromise  computing  resources  belonging  to  trusted 
administrators  -  hundred  of  thousands  of  computers  were  actually 
compromised.  -  Defects  are  an  enabler,  and  network 
connectivity  is  a  risk  factor. 

Use  computing  resources  such  as  the  USB  drives  used  by  system 
administrators  to  transfer  malware  to  the  control  systems  Use  of 

end-user  computing  resources  is  a  risk  factor. 

Use  control  system  extensibility  to  install  control  software  that 
would  adversely  change  the  behavior  of  existing  control  functions. 

Product  feature  is  an  enabler.  No  auditing  or  notification  of 

control  code  changes  are  design  faults  or  operational  faults. 
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Attack  Example:  Bank  Fraud 


Organizations  with  limited  IT  support  -  e.g.  school  districts 

Organization’s  computer  used  for  bank  transaction  is  compromised 

Malware  deployed  that  that  receives  and  can  transforms  web  pages  -  man-in  the 
middle 

When  user  logs  into  financial  system,  a  page  is  returned  that  informs  the  user 
that  there  will  short  delay  (while  malware  submits  transactions) 

Company  Bank 


Frequent  design  fault:  Financial  systems  assumed  client  has  not  been 
compromised.  Confirmations  for  fraudulent  transactions  returned  over 
compromised  communications  path  and  blocked  by  the  malware. 
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Attack  Examples 


Google:  Aurora  -  access  to  code  base 

•  Zero-day  IE  vulnerability 

•  Social  Engineering  -  targeted  employee  with  access  and 
used  chat  invitation  from  “friend”  to  install  malware 

RSA:  access  to  sensitive  information 

•  Social  engineering 

•  Flash  vulnerability 

Epsilon:  Access  to  email  addresses 

•  Social  engineering 
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Changing  Nature  of  Attacks 


Advanced  Persistent  Threat  (APT) 

•  Early  usage  of  the  term  typically  focused  on  the  source 
of  the  attack  such  as  nation  state,  organized  crime,  and 
terrorist  organizations 

•  After  Operation  Aurora  in  2010  APT  became  associated 
with  any  targeted,  sophisticated,  or  complex  attack, 
regardless  of  the  attacker,  motive,  origin,  or  method  of 
operation.  [IBM  2010  X-Force  Report] 
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Connectivity  and  Control1 


Limited  supply  chain  controls 

Product  assessments  occur 
after  development  completed 

No  knowledge  of  suppliers  to 
supplier 


Low  Control 


Commercial 
Products  and 
Systems 


Integrated  ^ 
Systems 


Few  Interconnections 

Custom 
Developed 


Monitor  supply 
chain  risks  during 
development 


Systems  of 
Systems 


exposure  to  operational  risks 

Reduced  knowledge  of  other  systems 

End-user  computing  devices  participate  in 
multiple  systems: 


Highly  Interconnected 


High  Control 
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Connectivity  and  Control2 


Low  Control 


Commercial 
Products  and 
Systems 


End-user 

Integrated  _ _  devjces  and 

Systems  "*  -- —  connections 

with  more 
systems 

Connectivity  risk  for  system  may 
come  from  increased 
connectivity  associated  with 
those  using  the  system 


Few  Interconn  actions 


Siemens  malware  example: 
Administrator’s  USB  drives 
compromised. 


Highly  Interconnected 


High  Control 
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Software  Supply  Chain  Risk  Management 
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Enablers:  Software  Errors 


MITRE  has  documented  software  errors  that  have  led  to 
exploitable  vulnerabilities:  Common  Weakness 
Enumeration  (CWE) 

CWE/SANS1  Top  25  Most  Dangerous  Programming  Errors 
published  yearly  by  MITRE  -  3/1/2010 


Examples 


Improper  Input  Validation 

Cross-site  scripting 

Download  of  Code  Without  Integrity 

Check 

Race  Condition 


SQL  Injection 

Use  of  Hard-coded  Credentials 

Improper  Check  for  Unusual  or 
Exceptional  Conditions 

Classic  Buffer  Overflow 


1.  http://cwe.mitre.org/top25/ 

SANS  (SysAdmin,  Audit,  Network,  Security)  Institute 
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Veracode:  State  of  Software  Security 

58%  of  all  applications  did  not  achieve  an  acceptable 
security  score  upon  first  submission  Fall  2010 

Measured  Against  CWE/SANS  Top-25  Errors 


Software  Source 

Acceptable 

Outsourced 

6% 

Open  Source 

39% 

Internally  Developed 

30% 

Commercial 

38% 
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Supplier:  Attack  Surface  Analysis 


Reduce  Attack  Surface 

•  Remove  or  change  system  features  or  re-architect  the 
implementation  to  avoid  attack  enablers  or  unnecessary 
channels. 

•  Revise  use  of  an  emerging  technology  where  there  is 
limited  knowledge  of  the  potential  exploits  and 
mitigations 

•  Review  requirements  or  implementation  if  existing 
mitigations  are  costly  or  do  not  provide  the  necessary 
assurance 
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Supplier:  Risk  Focused  Development 


Data  flow  analysis  (threat  modeling) 

•  Consider  known  weaknesses  and  attack  patterns  -  e.g. 
mix  of  data  and  commands 

•  Document  security  assumptions  and  trust  boundaries 

•  Consider  deployed  configuration  and  expected  usage 

•  Analyze  the  interfaces  to  other  components  (inputs  and 
outputs) 

•  Consider  consequences 

•  Analyze  possible  mitigations 

•  Provide  architecture  and  design  guidance 

•  Guides  testing 
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Secure  Software  Development 


Microsoft:  Security  Development  Lifecycle 

Build  Security  In  Maturity  Model  -  http://bsimm.com/ 

Open  Group  Trusted  Technology  Framework  for 
accreditation  of  technology  suppliers  -  under 
development  with  early  DoD  participation 

SafeCode  -  http://www.safecode.org/ 

Build-Security-In-Web  site  -  DHS 
https://buildsecuritvin.us-cert.gov/bsi/home.html 
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General  Purpose  End-User  Software 


End-user  software  has  always  been  a  target  for 
attackers 

•  Floppy  disks  — ►  Office  documents  — >  email  — ►  web 

Web  browser 

•  Attackers’  objective  to  have  user  execute  their  code 

—  Extensibility  -  JavaScript,  Ajax,  ActiveX 

•  HTML5  increases  browser  attack  surface 

Mobile  devices 
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Software  products  -  systems 


Unacceptable  risks  identified  during  a  product 
assessment  can  lead  to  a  rejection  -  some 
financial  service  organization  use  tests  similar  to 
Veracode 

Product  assessment  criteria  must  reflect  the  criticality 
of  usage  and  the  level  of  assurance  required. 

High  No  known  failures 

Medium  Known  vulnerabilities  addressed 

Low  Failure  can  be  tolerated  -  low  consequence 


Open  question:  Can  low  assurance  components  be 
used  in  a  medium  assurance  system? 
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Systems 


A  systems  perspective  captures  product  usage  and 
consequences  associated  with  supply  chain  risks. 

•  Changing  threat  landscape 

•  Increasing  demand  for  leading-edge  software  with  not 
well  understood  risks 

•  A  product’s  proposed  usage  and  attack  opportunities  can 
require  mitigations  beyond  those  provided  with  the 
product  -  also  applies  to  legacy  systems 

•  The  trust  among  components  implied  by  the  integration 

•  As  we  go  forward  (Cloud  Computing)  the  guidance 
should  be  Don’t  trust  but  verify1 

1:  Gunnar  Peterson,  IEEE  Security  and  Privacy,  SEPTEMBER /OCTOBER  2010 
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Stronger  Custom  Developer  Criteria 


Applying  of  practices  such  as  threat  modeling  at  the 
system  level  can  more  demanding  than  for  a 
product 

•  Product  development 

—  Long  product  life  -  incremental 

Concentrate  on  software  weaknesses  appropriate  to  that 
supplier’s  domain  and  products  -  guided  by  product  history 

Relatively  small  and  stable  set  of  suppliers 

•  An  integration  contractor  or  custom  system  developer 

—  multiple  one-off  relatively  short-lived  efforts 

—  multiple  functional  domains 

multiple  sets  of  applicable  software  products,  suppliers,  and 
subcontractors 
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T  rade-Offs 


A  simplified  design  to  reduce  cost  or  speed  delivery 
may  not  provide  adequate  mitigations  for  known 
operational  risks. 

Products  that  support  end-user  runtime  customization 
can  provide  that  same  capability  to  an  attacker. 

The  use  of  emerging  technologies  with  exploits  that 
are  not  well  understood  increases  risk. 

System  functionality  may  have  to  be  changed  or  a 
higher  risk  accepted  if  mitigation  costs  for  a  desired 
feature  are  too  high  or  if  residual  risks  for  known 
mitigations  are  higher  than  anticipated. 
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Supply  Chain  Control  Limitations 


Total  prevention  is  not  feasible  because  of  the  sheer 
number  of  risks;  limited  supply  chain  visibility; 
uncertainty  of  product  assurance;  and  evolving 
nature  of  threats,  usage,  and  product  functionality 

Defense-in-depth  does  not  necessarily  reduce  risks  - 
we  often  do  not  understand  interactions  among 
multiple  mitigations. 
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Operations  Over  Time 


Supply  chain  risk  mitigation  is  not  a  one-time  event 

•  New  attack  techniques  and  software  weaknesses  may 
be  discovered. 

•  Product  upgrades  that  add  features  or  change  design 
can  invalidate  the  results  of  prior  risk  assessments  and 
may  introduce  vulnerabilities. 

•  Corporate  mergers,  new  subcontractors,  or  changes  in 
corporate  policies,  staff  training,  or  software 
development  processes  may  eliminate  expected  SCRM 
practices. 

•  Product  criticality  may  increase  with  new  or  expanded 
usage. 
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Summary 


Increased  connectivity  and  interoperability  raise  the 
value  of  considering  supply  chain  risks  for 
secondary  applications. 

Techniques  exist  to  reduce  occurrence  of  software 
vulnerabilities  but  are  not  yet  widely  applied. 

A  systems  perspective,  particularly  in  deployment, 
captures  product  usage  and  consequences 
associated  with  supply  chain  risks. 

•  Component  update  or  replacement 

•  Change  in  usage 

•  Evolving  threats 


Software  Engineering  Institute  Carnegie  Mellon 


27 


Sources 


Software  Supply  Chain  Risk  Management:  From  Products  to  Systems 
of  Systems 

•  http://www.sei.cmu.edu/library/abstracts/reports/10tn026.cfm 

Evaluating  and  Mitigating  Software  Supply  Chain  Security  Risks 

•  http://www.sei.cmu.edu/librarv/abstracts/reports/1  OtnOI  6.cfm 

Attack  Surface 

•  Michael  Howard,  2003,  http://msdn.microsoft.com/en-us/library/ms972812.aspx 

Threat  Modeling 

•  Frank  Swiderski,  Window  Snyder,  Threat  Modeling,  2004 

•  Michael  Howard  and  Steve  Lipner.  The  Security  Development  Lifecycle, 
2006 

•  James  McGovern,  &  Gunnar  Peterson.  “10  Quick,  Dirty,  and  Cheap  Things 
to  Improve  Enterprise  Security.”  Security  &  Privacy,  IEEE,  March-April  2010 

•  Building  Security  In  Maturity  Model  (BSIMM)  http://bsimm2.com/index.php 

•  John  Stevens,  “Threat  Modeling —  Perhaps  It’s  Time”,  Security  &  Privacy, 
IEEE,  May-June  2010 

Software  Engineering  Institute  Carnegie  Mellon  28 


NO  WARRANTY 

THIS  MATERIAL  OF  CARNEGIE  MELLON  UNIVERSITY  AND  ITS  SOFTWARE  ENGINEERING 
INSTITUTE  IS  FURNISHED  ON  AN  “AS-IS"  BASIS.  CARNEGIE  MELLON  UNIVERSITY  MAKES  NO 
WARRANTIES  OF  ANY  KIND,  EITHER  EXPRESSED  OR  IMPLIED,  AS  TO  ANY  MATTER  INCLUDING, 
BUT  NOT  LIMITED  TO,  WARRANTY  OF  FITNESS  FOR  PURPOSE  OR  MERCHANTABILITY, 
EXCLUSIVITY,  OR  RESULTS  OBTAINED  FROM  USE  OF  THE  MATERIAL.  CARNEGIE  MELLON 
UNIVERSITY  DOES  NOT  MAKE  ANY  WARRANTY  OF  ANY  KIND  WITH  RESPECT  TO  FREEDOM 
FROM  PATENT,  TRADEMARK,  OR  COPYRIGHT  INFRINGEMENT. 

Use  of  any  trademarks  in  this  presentation  is  not  intended  in  any  way  to  infringe  on  the  rights  of  the 
trademark  holder. 

This  Presentation  may  be  reproduced  in  its  entirety,  without  modification,  and  freely  distributed  in  written  or 
electronic  form  without  requesting  formal  permission.  Permission  is  required  for  any  other  use.  Requests 
for  permission  should  be  directed  to  the  Software  Engineering  Institute  at  permission@sei.cmu.edu. 

This  work  was  created  in  the  performance  of  Federal  Government  Contract  Number  FA8721-05-C-0003 
with  Carnegie  Mellon  University  for  the  operation  of  the  Software  Engineering  Institute,  a  federally  funded 
research  and  development  center.  The  Government  of  the  United  States  has  a  royalty-free  government- 
purpose  license  to  use,  duplicate,  or  disclose  the  work,  in  whole  or  in  part  and  in  any  manner,  and  to  have 
or  permit  others  to  do  so,  for  government  purposes  pursuant  to  the  copyright  license  under  the  clause  at 
252.227-7013. 


Software  Engineering  Institute  |  Carnegie  Mellon 


29 


